1. Technical Field
The present invention relates generally to computer security and authentication. More particularly, the present invention relates to methods for issuing, validating, and revoking client certificates utilized in connection with bi-directional authentication between client and server computer systems.
2. Related Art
Banking, financial services, government education, and all varieties of enterprises rely upon advanced computer systems and data communications such as the Internet to transact and share information. While these advancements have greatly increased the speed and convenience with which business is conducted, numerous vulnerabilities can potentially compromise the security of the highly sensitive and confidential data being exchanged.
In an open network environment, the primary concern of data security is three-fold. First, the server must be assured that the server is what it asserts it is. Second, the client must be assured that the server is what it asserts it is. Third, any information being exchanged between a legitimate server and a legitimate client must not be intercepted or changed by any other computer system on the network.
The Public Key Infrastructure (PKI) is widely utilized to facilitate online transactions and address the aforementioned data security concerns. In general, public key encryption, also referred to as asymmetric-key encryption, involves a unique public/private key pair held by both the recipient of a message and its sender. When transmitting a message, the sender's private key and the recipient's public key are used to encrypt it. Upon receipt, the message is decrypted with the recipient's private key. The recipient's public key held by the sender corresponds to the recipient's private key, and only such private key is capable of decrypting the message. In proper implementations, it is understood that the private key cannot be derived from the corresponding public key.
In addition to the encryption and decryption functions, the cryptographic keys can be used to authenticate the message as being from the actual sender as it is purported to be. Specifically, a hash value of the message is generated, and the hash value is signed with the private key of the sender of the message to generate a message signature. These signatures may be generated according to a variety of well-known algorithms such as the Public Key Cryptography Standards #1 (PKCS#1), the Digital Signature Algorithm (DSA), the Secure Hash Algorithm (SHA), and others. Once received, the recipient confirms the authenticity of the message by validating the accompanying signature of the sender against the public key of the sender. A comparison of an independently generated hash value of the message against the received hash value validates the integrity of the message.
In a conventional public key infrastructure, the public key is bound to a particular identity by a certificate authority (CA) in a digital certificate that is issued following a registration and verification process. The CA is understood to be a trusted third party, and is responsible for confirming the identity of those to which it is issuing a digital certificate, whether that is an individual user, a specific machine or a set of machines in a network, an organization, or any other entity. The public key is signed with the digital signature of the CA to validate the digital certificate to any recipients thereof.
Digital certificates are utilized in a wide variety of contexts including e-commerce and enterprise data access that involve data exchange over open networks. Due to the availability of numerous client applications and servers implementing encryption and validation systems with digital certificates, the X.509 standard, which governs the structure and format thereof, has been promulgated. One common application is secure websites (https) in which the servers communicate with compliant browser clients over the Secure Sockets Layer/Transport Layer Security (SSL/TLS) protocol. SSL/TLS is understood to be a cryptographic protocol that provides data exchanges safe from eavesdropping, tampering, and forgery, and operates on the protocol layers below application-layer protocols such as the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP), but above transport-level protocols. SSL/TLS is not limited to HTTP, and other application-layer protocols such as Simple Mail Transfer Protocol (SMTP), Internet Message Access Protocol (IMAP), Post Office Protocol (POP), File Transfer Protocol (FTP) and the like may be carried over an SSL/TLS connection.
In establishing an SSL/TLS connection between a client and a server, the digital certificate for the server is transferred to the client for validation and encryption handshaking purposes. As indicated above, a third party CA signs the digital certificate, and the client validates the CA signature therein to ensure that it is, indeed, establishing a connection to the proper server. A session key based upon the received server public key may then be sent to the server to encrypt subsequent data.
Most conventional SSL/TLS servers deploy only server-side authentication as above, and so the client side remains unauthenticated to the server except via the most basic password-based access control modalities that have a substantial likelihood of being compromised. Client-side TLS can be utilized to establish a bilateral trust between the server and the client, which involves the installation of a private/public key pair on the client. The server validates the corresponding client certificate, which includes the public key signed by the CA, in the same manner as with the server certificate. Improvements over client-side TLS such as the SecureAuth system developed by MultiFactor Corporation of Irvine, Calif., the assignee of the present application, contemplate the issuance of digital certificates to the client as a second authentication factor.
Regardless of the particular uses, the issuance and revocation of the digital certificates is relatively uniform. In further detail, a digital certificate is understood to have subject data such as a user name, an expiration date, a public/private key pair, and a signature from a trusted CA. However, the validity of the digital certificate is based upon the expiration date and the signature, so if it has not yet expired and properly signed by a CA, then it is considered to be a valid credential.
A significant limitation of PKI is that once the certificate is issued, it will be considered a valid credential until it expires, and does not account for the possibility that the end user associated therewith is no longer permitted access due to departure from the organization, a change in access privileges, compromise of the digital certificate necessitating a re-issuance, and so forth. Because it may not be practical to retrieve the digital certificate, earlier systems have considered the use of a first list of all valid credentials, and a second list of all invalid credentials. One such system is the certificate revocation list or CRL (RFC 1422), which is a list of certificates that have been revoked or are no longer valid, and are consulted prior to validating the digital certificate. A CRL is periodically generated and published by the CA. Another modality is the Online Certificate Status Protocol or OCSP (RFC 2560), which is a communications protocol for querying the revocation status of the digital certificate.
Although OCSP represents an improvement over CRLs, both systems have inherent weaknesses that render deployment and maintenance difficult. Even after removing a user account from the system, the outstanding digital certificate may nevertheless allow access; in other words, digital certificate management is completely independent of the system users management. Moreover, the retrieval and consultation of a potentially large volume of data pertaining to the revoked/invalid certificates at each validation instance may place a significant burden on processing and network bandwidth resources. Accordingly, such systems found limited application only in small business-to-employee networks. The costs and complexity associated with the implementation of such systems in business-to-customer and web environments have altogether precluded market acceptance.
In light of these limitations, there exists a need in the art for methods for identity-based certificate management.